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Abstract 

Information system professionals strive to determine requirements by interviewing clients, observing 
activities at the client's site, and studying existing system documentation. Still this often leads to 
vague and inaccurate requirements documentation. When teaching the skills needed to determine 
requirements, it is important to recreate a realistic environment to develop analytical thinking skills. 
To address this, we developed a simulation for students to learn requirements gathering and analysis 
where they experience the requirements by operating a fictitious manufacturing firm. The students 
manage and operate the company, taking on a variety of employee roles from the physical 
"manufacturing" to the order-taking to the purchasing of component parts. With this pedagogical 
approach, students deal with the messiness of the problem by drawing on their own experience 
working in the manufacturing firm, making assumptions, and having the opportunity to verify their 
assumptions and analyses by working with their classmates. The simulation was implemented across 
two courses in an undergraduate information systems program. 

Keywords: simulation, requirements determination, pedagogy, modeling, active learning 


1. INTRODUCTION 

Requirements determination and documentation 
of business needs through modeling techniques, 
such as data flow, entity relationship, and UML 
diagrams, are critical skills for information 
system (IS) practitioners. In the field, a 
systems analyst or project team will determine 
requirements by interviewing clients and users, 
observing activities at the client's site, and 
studying existing system documentation. Often 
the information initially provided by the client is 
incomplete, not 100% accurate, and presented 
in an illogical sequence. If the analyst or project 


team fails to identify the missing and/or 
misrepresented needs of the client, the system 
will be flawed at implementation, as it will not be 
aligned with the true requirements and business 
needs. This potentially leads to failure of 
expectations and wasted resources. 

One objective in teaching requirements 
determination and analysis is creating a problem 
domain that students can comprehend with a 
level of complexity that is neither too simple to 
present a genuine challenge nor too difficult to 
understand and model. The effort of creating 
effective learning material is amplified given the 
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background of students varies both within and 
across universities. Some textbook scenarios, 
case studies, and assignments that are used to 
educate and train IS undergraduate students 
describe the problem domain by providing a list 
of requirements. These lists come in a variety of 
forms, such as bulleted lists, paragraphs, and 
videos. This effectively provides students with 
an opportunity to practice the syntax of the 
specified modeling approach, but the 
opportunity to actually analyze the business 
situation is limited. 

When students find, however, that the exercises 
are too vague or complicated, due to their 
limited business background, students may 
perceive there is no mechanism to clarify their 
own assumptions, making them hesitant to state 
those assumptions, draw models, and formulate 
decisions based on the information provided. 
When the students find the exercises are too 
neatly packaged or too simple, the modeling 
exercises may become overly repetitive and 
routine as it is not necessary for students to 
make their own assumptions or draw 
conclusions. Understanding when one needs to 
make an assumption, making the assumption, 
and determining how to verify its 
appropriateness are critical skills to develop as 
part of requirements determination. When using 
traditional textbook exercises, it is difficult to 
create realistic experiences for students because 
static text is not interactive and cannot respond 
to specific questions as they emerge during the 
problem-solving phase of the exercise. To be 
successful in the information systems profession, 
a systems analyst must be able to identify the 
weaknesses inherent in information provided, 
analyze the situation, and devise a strategy to 
elicit the true requirements. This involves 
walking a fine line between both gathering 
information and questioning it at the same time. 

To better prepare students for the industry, we 
developed an in-class simulation that provides 
students with exposure to a requirements 
determination process that incorporates 
vagueness, incomplete information, and the 
opportunity to acquire incorrect information 
and/or perspectives. This, as a result, forces 
students to make assumptions and seek to 
verify them, bringing together the gathering and 
questioning of information. We sought to create 
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an experience where students would be 
motivated to dive into the messiness of the 
problem in an environment where information 
gathering and requirements development would 
be required before modeling, instead of having 
requirements simply listed. With this 
pedagogical approach, students deal with the 
messiness of the problem by drawing on their 
own experience working in a manufacturing firm, 
making assumptions, and verifying their 
assumptions and analyses by working with their 
classmates. The following sections of this paper 
describe prior literature, this didactic approach, 
and the implementation of the approach. 

2. LITERATURE REVIEW 

Requirements Determination 

Requirements determination starts with the 
scope statement and leads to a list of specific 
functional and non-functional requirements that 
must be met to create the deliverable described 
in the scope statements (Dennis et al., 2012). 
Also called requirements discovery, 
requirements determination is a process of fact 
finding where a variety of tools and techniques 
can be used, such as stakeholder interviews, 
observation and document analysis (Whitten and 
Bentley, 2007). By studying existing 
procedures, reports and forms, an analyst can 
uncover both problems with the existing system 
and also opportunities to enhance system 
capabilities in a new system (Hoffer et al., 
2014). Studies have shown that a flaw found in 
a system after it has been released to users can 
cost from 10 to 100 times more than if it had 
been identified and resolved when the 
requirements were being determined 
(McConnell, 2004). This suggests that learning 
how to determine system requirements is a 
critical component in educating information 
systems students, and successful learning 
activities may lead to improved systems quality 
and reduced costs. 

Although there is substantial research on 
requirements elicitation, knowledge acquisition 
and requirements analysis (Byrd et al., 1992), 
little research is available on the pedagogy of 
preparing a student to know to apply the theory 
they have learned in the classroom (Hanchey, 
2002). Prototyping tools are one technology 
that has been used in the classroom to develop 
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students' requirements determination skills. 
Dalai (2012) used "rapid game prototyping" in 
an assignment requiring students to build a 
game using one of their personal friends or a 
family member to provide the game 
requirements. 

Inquiry-Based Learning 

Another successful approach is inquiry-based 
learning, which is a student centered approach 
to learning where, given a scenario or goal, the 
student acts as a detective, asking questions 
and performing research (Hu et al., 2008). It 
has been demonstrated that inquiry-based 
learning not only contributes to improved 
learning in specific contexts, but it is also 
associated with intellectual development (Hu et 
al., 2008). Simulations present the opportunity 
for inquiry-based learning as participants 
interact and explore possibilities. Using 
simulations in the classroom is an instructional 
strategy where students are engaged in the 
discovery of knowledge rather than the recipient 
of static information (Queen, 1984). A 
simulation is a model of a real-world 
phenomenon. As such, the simulation is an 
abstraction or simplification of the real thing that 
includes only the aspects of the target necessary 
to achieve the learning goals. 

Simulation Types 

There are four types of educational simulations: 
physical, iterative, procedural, and situational 
(Lunce, 2006). In a physical simulation, a 
student has the opportunity to change a system 
characteristic, such as level of production or 
routing pattern, and then watch the result. In 
the iterative simulation, a student develops 
hypotheses regarding a system parameter, and 
then observes the results after altering the 
parameter to test the various hypotheses. The 
results are observed and then the alteration- 
observation pattern is repeated until the learner 
develops a thorough understanding of how the 
altered parameter affects the construct of 
interest. In a procedural simulation, a student 
learns how to operate by observing processes 
and steps, such as a flight simulator. Finally, a 
situational simulation involves a goal-directed, 
role-playing exercises. 

Furthermore, simulations can be individual or 
group activities. Studies have shown that 
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groups consistently outperform individuals in 
many types of activities, and team-based 
projects in academic settings, such as 
information systems courses, lend themselves 
well to a constructivist approach to learning 
(Keys, 2003; Derrick & Haggerty, 2001; Cronan 
& Douglas, 2012). The group simulation 
provides a shared experience for the 
participants, and both common intellectual 
experiences and collaborative projects are 
considered high-impact educational practices 
(Kuh, 2008). 

Classroom Simulations and Active Learning 

Classroom simulations require active student 
involvement, which leads to a deeper 
understanding of the issues (Montgomery et al., 
1997). Active learning, experiential learning, 
and constructivism are essentially synonymous 
terms for a student learning by doing or 
engaging. Kolb (1984) described experiential 
learning theory as "a holistic integrative 
perspective on learning that combines 
experience, perception, and behavior." Thus 
learning is not viewed as a final state where 
knowledge has been acquired; rather it is 
viewed as a process where the learner interacts 
with the environment. On the other hand, in the 
traditional classroom lecture, an instructivistic 
approach, the student is viewed as a passive 
receptacle. Leemkuil et al. (2003) describe 
instructivism as "characterized by the explicit 
presentation of non-arbitrary relationships 
between pieces of information to learners" (p. 
100). Thus the lecture may be an effective way 
for a student to acquire knowledge of facts and 
procedures. Lectures alone, however, fail to 
communicate how challenging it is to apply that 
knowledge in a professional setting (Jeffries, 
2005). This suggests that utilizing multiple 
educational strategies can be useful in the 
classroom. 

Studies across disciplines consistently find that 
experiential learning is deeper and more 
enduring than the rote memorization, which 
often accompanies the classroom lecture. Kolb 
(1984) identified four specific stages learners 
proceed through to develop understanding: 1- 
concrete experience, 2-reflective observation, 3- 
abstract conceptualization, and 4-active 
experimentation. In other words, Kolb said the 
learner must interact with the learning target, 
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think about the experience, generalize their 
understanding of the experience, and then test 
their generalized theory. Montgomery et al. 
(1997) applied Kolb's four step experiential 
learning process in an introductory education 
class. To gain concrete experience, the students 
attended a local school board meeting. Then the 
students engaged in reflective observation by 
discussing their experience in the classroom. 
The third phase, abstract conceptualization, 
required students to assume the role of a board 
member and "prepare for the simulation through 
researching the stakeholder's role and writing a 
grant proposal to present during the simulation" 
(p. 223). They found that because the students 
participated in the simulated board meeting, 
they had a deep understanding of the 
responsibility and influence of the U.S. 
educational system. Leemkuil et al. (2003) used 
a physical simulation to train people in the area 
of knowledge management, and demonstrated 
the importance of both providing domain 
instruction to prepare students for the 
simulation and also debriefing the students 
afterwards. These finding are consistent with 
Kolb's four abilities model. 

The nursing education literature also suggests 
that educational simulations, particularly 
physical clinical simulations, lead to longer 
retention of knowledge, development of skills 
that are directly applicable in patient care, and 
increased confidence (Jeffries, 2005). 
Simulations are commonly used in business 
schools, particularly in operations and supply 
chain management. Perhaps the most well 
recognized supply-chain simulation is the "Beer 
Game," a physical simulation, which was 
developed at MIT. The game demonstrates how 
small changes in downstream demand (e.g. 
consumer purchases) can lead to big changes in 
upstream order quantities (e.g. manufacturer / 
work orders), a phenomenon call the bullwhip 
effect. What is compelling about the "Beer 
Game" is how clearly participants can see the 
bullwhip effect and that the manifestation of the 
bullwhip effect occurs regardless of who is 
participating (Goodwin & Franking, 1994). 
Klassen and Willoughby (2003) developed a 
similar simulation, but their version included the 
costs associated with over-ordering and 
shortages. They found that those participating 
in the simulation not only increased their general 
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knowledge of inventory management, but also 
gained an appreciation for the complexity of the 
problem. Bandy (2005) also used an in-class 
simulation to demonstrate the benefits of 
pooling safety stock across decentralized 
locations. Subsequent student performance on a 
quiz and the results of a survey given to the 
students after the simulation both indicated that 
the simulation was instrumental in students 
understanding the benefits of pooling safety 
stock. 

Engaging students in an active learning process 
by employing a physical simulation creates an 
opportunity for greater understanding of the 
theory taught in the classroom. This technique 
can enable students to better understand how to 
effectively discover the needs of the client and 
develop better solutions to the business 
problems. 

3. PEDAGOGICAL APPROACH 

To encourage inquiry-based and active learning 
in a group experience, a simulation was 
developed situated around a company called 
Fetch, Inc., a fictional manufacturing firm. This 
is a physical simulation where the students 
manipulate production levels and the purchasing 
pattern of raw goods inventory. To develop a 
learning experience where the learner interacts 
with the environment, it was required to create 
such an environment. 

To understand and gather the requirements, the 
students manage and operate the company, 
taking on a variety of employee roles from the 
physical "manufacturing" to order taking to 
purchasing of component parts. While working 
at Fetch, students experience the manufacturing 
process grind to a halt as component parts 
become unavailable, which is based on their 
chosen production levels and purchasing 
patterns. Neither management nor the 
purchasing department is in a position to correct 
the problem, because they are all working with 
bad information, whether it is stale or simply 
inaccurate. The experience of working at Fetch 
provides students with both a low-level detailed 
experience based on their role and a high-level 
overview of how the departments operate and 
experience failure. To control the complexity of 
the simulation, we opted to not include any 
financial information. The key focus is on 
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inventory quantities as accurate inventory 
management is necessary for consistent, timely 
production of finished goods. 

Although the context of this simulation is 
operations management, the learning objective 
is not related to operations management. Our 
objective is to develop and refine requirements 
determination and modeling skills. All 
information systems projects are embedded in 
some business context. We chose the 
manufacturing context because we were able to 
model the business context using tinker toys. 
We believe this physical simulation made the 
business context more understandable to the 
students in comparison to other less tangible 
contexts, like accounting or marketing. 

Throughout the remainder of the semester, 
students model the processes they experienced 
in the simulation, identify the problems and 
requirements necessary to fix the problems, and 
model the solution that can be supported by a 
new information system. With this didactic 
approach, students deal with the messiness of 
the problem by drawing on their own experience 
working at Fetch, review the documentation 
generated during the simulation, make 
assumptions, and have the opportunity to verify 
their assumptions and analyses by working with 
other Fetch employees - their classmates. 

Simulation Administrative Details 

The simulation takes approximately 1 hour to 
conduct. Flowever, the students utilize the 
experience gained during the 1 hour for many 
weeks in the semester, including during class, 
group meetings, and the creation of 
deliverables. For the simulation, students are 
assigned roles in one of the various departments 
and issued job descriptions, which included what 
their responsibilities are and any artifacts 
needed to complete their work. These 
departments are: manufacturing, quality control, 
shipping, order entry, operations management, 
purchasing, and general management. Four to 
six students are assigned to manufacturing, 
shipping, order entry, and purchasing. One to 
two students are assigned to quality control, 
operations management, and general 
management. In addition to the instructor and 
students, the simulation requires two additional 
assistants to run. One assistant is responsible 
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for feeding orders (via dropping paper slips in an 
inbox) to the order entry department, and the 
other assistant is responsible for receiving and 
fulfilling orders placed by the purchasing 
department. In order to fulfill the orders for 
component parts, this second assistant should 
also accumulate product shipped by Fetch so 
that he/she can disassemble them and use those 
pieces for fulfillment. It is recommended that 
this person has a station external to the main 
simulation room. See Appendix A for other steps 
necessary to conduct the simulation. 

Supporting Materials 

Over twenty artifacts were developed to support 
the operation of Fetch, Inc., including job 
descriptions for each role, forms, and report 
templates. These are available by request from 
the authors. For example, Appendix B describes 
the procedures that the purchase order clerk is 
to follow, which is included in the job description 
for the role. In order to complete these 
instructions, the Purchase Order (PO) clerk 
needs to work with the following documents: 
Reorder Point Memo, Raw Goods Inventory on 
Fland Report., Suppliers List, Price List, Purchase 
Orders, and the Purchase Order Ledger. Each of 
these was prepared prior to the simulation. 

Simulation Execution 

The "manufacturing" was performed by students 
in the role of shop floor employee. Students 
"built" products using Tinker Toys as raw 
materials and a bill of materials that described 
the component parts and assembly of each 
product (see Figure 1 for sample portion of the 
BOM). The simulation was driven by fictional 
email messages containing customer orders. 
The operations of the company includes 
everything from recording customer orders, 
manufacturing products, purchasing raw 
materials, building, inspecting, and shipping 
products. Communication regarding work 
performed is conducted within and across 
departments using the forms and report 
templates provided for the department. 
Departments can send these forms, as specified 
in the instructions, to each other using the 
department mailboxes. 

The work procedures given to the participants 
are logically sound. The overlapping and loosely 
coordinated activities of the functional areas, 
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however, inevitably lead to a work stoppage as 
raw materials are consumed, not adequately 
replaced, and customer orders consequently 
cannot be manufactured and shipped. Thus, 
within one hour of "operating" Fetch, the system 
breaks down. 


Portable 

Scanner 


Red Bulb 
Pink Clip 
Green 
Flipper 
Orange Rod 
8 Hole Disk 



First join 
the Orange 
Rod with 8 
Hole Disk. 
Be sure to 
secure 
firmly. 

Then attach 
the other 
end of the 
Orange Rod 
to its ... 


Figure 1. Excerpt from Bill of Materials 


Debriefing and Classroom Application 

At the end of the simulation, the number of 
orders and the order metrics (customer orders, 
work orders, purchase orders and open, closed, 
waiting to ship orders) are counted as a 
mechanism for measuring performance of the 
session. Immediately following the simulation, a 
debrief should be held to elicit ideas from the 
students as to why the system breaks and what 
can be done to fix it. The order metrics are also 
presented at the debrief. The specific cause of 
the failure and subsequent low metrics is a delay 
in communicating both the consumption of raw 
material and the shipment of finished goods 
inventory - an information problem. In other 
words, demand is realized too late in the 
process. It is the system's failure that becomes 
the main focus of the exercises and assignments 
following the simulation. Throughout the 
remainder of the semester, students create 
diagrams modeling the user requirements, data 
structures, and processes for an information 
system that could correct the inherent data 
timing and quality problems in the operations of 
Fetch, Inc. To create these models, students 
use their own simulation experience, interview 
their classmates, and study documentation and 
forms used in the simulation. See Appendix A 
for a listing of the forms and reports used in the 
simulation. 


4. IMPLEMENTATION OF THE PEDAGOGY 

The pedagogical approach was implemented 
across two courses, bringing together related 
concepts from a Systems Analysis and Design 
course and a Data and Information Management 
course. These two courses are the first two 
taken by Information Systems Management 
majors in the Palumbo-Donahue School of 
Business at Duquesne University. As these 
courses are typically taken by first semester 
juniors, 85 to 90 percent of the students are 
registered in both courses simultaneously. This 
implementation was innovative in its own right 
because it allowed the instructors to 
demonstrate cross-course concepts 
determining and documenting requirements to 
serve as the basis for information system 
design. This process is a critical skill for 
students studying information systems and is 
directly related to both courses. The Systems 
Analysis and Design course focuses on how to 
determine the requirements of an application 
(e.g., what actions must be accomplished by the 
users of the system), while Data and 

Information Management course focuses on the 
requirements for data storage (e.g., what 
information needs to be stored and accessed). 
Further, both courses provide students with 
skills necessary for creating diagrams and other 
artifacts to document requirements using 
industry-standard modeling methodologies. The 
simulation could be used in either course 
independently, however. 

Prior to the day of the simulation, students were 
briefed in the classroom to ensure their 
familiarity with the business context. The 
briefing reviewed a manufacture-to-stock 
scenario where (1) customer orders deplete 
finished good inventory, (2) a reduction in 
finished goods triggers work orders to 
manufacture more product, (3) the 
manufacturing process consumes raw goods 
inventory, (4) and reductions in raw goods 
triggers purchase orders for the component 
parts. Industry-standard modeling 

methodologies are covered throughout the 
courses. 
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Figure 2. Plant Layout 


In order to conduct the simulation in a 
classroom, the room was transformed into a 
"plant layout". The classroom furniture was 
arranged in a way that suggested there were 
seven different work areas (see Figure 2). Each 
area or department had a sign indicating the 
function performed there. Products in different 
stages of production were placed at different 
work areas to create the illusion of on-going 
operations at the start of the simulation. 


5. Analysis 

96 students participated in the simulation and 
were assigned to one of 4 sessions. Within 30 
to 40 minutes, each of the sessions led to a 
system breakdown, as predicted. The order 
metrics (customer orders, work orders, purchase 
orders and open, closed, waiting to ship) were 
collected for each session (see Table 1). 



Cos 

WOs 

POs 

Session 

C 

O 

W 

C 

O 

C 

O 

A 

8 

7 

2 

4 

10 

10 

6 

B 

8 

5 

7 

7 

10 

5 

3 

c 

6 

7 

8 

8 

11 

10 

7 

D 

4 

5 

8 

8 

6 

12 

0 

C-closed, O-opened, W-waiting to ship 


Table 1. Final Order Statistics 


Debriefing 

The class session after the simulation, the 
students were debriefed on their experience. 
They were asked: 

• With all the open orders and work-in- 
process, why weren't you, as employees, 
working? 


• Why was everyone sitting around 
waiting when customers weren't 
receiving the products they ordered? 

Listening to the students responses, it was clear 
to the them that (1) the shipping department 
was not shipping because the ordered parts 
were not in inventory, (2) the shop floor was not 
working because the component parts were not 
available in the raw goods inventory, and (3) the 
purchasing department was not ordering 
because the shop floor did not report the use of 
raw goods until after the work on the customer's 
order was done. At this point it was clear to all 
that the movement of parts needed to be 
reported as soon as the parts were pulled out of 
inventory. Carrying excess inventory would hide 
this problem, but not solve it. Better inventory 
practices such as just-in-time or lean would only 
exacerbate the problem. The above issues were 
independent of who was participating. They 
occurred in every session of the simulation. 

There were additional problems that occurred as 
individuals made adjustments to the procedures 
to solve local issues without knowledge of how it 
would affect the overall process. For example, 
one of the purchasing clerks decided to order 
larger quantities of all parts so the shop floor 
would have everything they needed. The 
student was unaware that the availability of 
component parts was limited (this is realistic - 
scarcity or lead-time issues), and an assistant 
who helped run the simulation by receiving 
newly shipped customer orders was instructed 
not to "ship" partial orders for component parts 
(realistic - shipping costs). What physically 
happened was that the shop floor was waiting 
for component parts to enter raw goods 
inventory to finish building the product. New 
pieces, however, could only be made available 
when the assistant received finished products 
and could disassemble them to fill orders for 
component parts. No orders were leaving the 
plant because they were waiting on component 
parts. No parts were entering the plant because 
the assistant was waiting to disassemble shipped 
finish products, which would not be available 
because they were stalled in the manufacturing 
process. 
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Attitudinal Survey 

An attitudinal survey was administered after the 
simulation was complete, but prior to the 
debriefing. Seven questions were used to assess 
the students' impressions of the simulation (see 
Appendix C) with a 7-point Likert scale from 
strongly disagree to strongly agree. Three areas 
were addressed. One, they were asked about 
the relative learning productivity of the 
simulation and should it be used again. Two, 
they were asked which was more enjoyable - 
the simulation or traditional lectures. Third, 
they were asked if they better understood the 
effort required to effectively work in teams. 

We discarded 6 of the 96 participants responses 
because they answered both questions on 
enjoyment with the same response, and one 
item was reverse coded (response was not "4 = 
Neither Agree nor Disagree" in any of these 
cases). The results showed that no more than 
four students (out of the 90) responded 
negatively to the learning effectiveness or 
enjoyment of the activity. Over 84% of the 
respondents reported a greater appreciation for 
working in teams. Lastly, only two respondents 
would recommend we not use the simulation 
again. 

Post-simulation Learning Goals 

In addition to the one-hour simulation and the 
briefing and debriefing, students were given 
access to all the supporting documentation 
which includes job descriptions, work 
procedures, forms, report formats, and students 
were encouraged to interview one another about 
their experience and understanding of Fetch's 
operations. Thus the process of discovering and 
analyzing requirements continued throughout 
the remainder of the 15 week course. 

The purpose of the simulation was to create an 
experience where students understood the 
complexity surrounding requirements 
determination and documentation; the purpose 
of the assignments was for the students to apply 
that understanding and for the instructors to 
assess the learning outcomes. Specific learning 
goals for the courses to measure learning are 
shown in Table 2. 
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Learning Goal 

Measure (Evidence) 

Learning Goal 1 (381 
W): The student will 

be able to evaluate 

the current system 

and determine the 

requirements for 
creating an improved 
system. 

• UML Model assignments 

• Entity Relationship Model 
assignments 

• Data Flow Model 

assignments 

• Use Case assignments 

Learning Goal 2 (381 
W): The student will 

be able to model 

system requirements 
using object-oriented 
modelinq techniques. 

• UML Model assignments 

o Functional Models 

o Structural models 

o Behavioral Models 

Learning Goal 3 (381 
W): The student will 

be able to model 

system requirements 
using process- 
oriented techniques. 

• Process Model assignment 

• Multi-level Data Flow 

Diagram 

Learning Goal 4 
(382): The student 

will be able to model 

system requirements 
using data-oriented 
modelinq techniques. 

• Entity Relationship 
Diagrams incorporated 
into course project 

Learning Goal 5 
(382): The student 

will be able to build a 

functioning database 
to support their data 

model. 

• Creation of a functional 

database using MS SQL 
Server as part of course 
project. 


Table 2. Learning Goals 


For each of the learning goals in Table 2, 
student assignments completed post-simulation 
are specified as evidence that they have met the 
goal. The first three goals are part of the 
Systems Analysis and Design syllabus, whereas 
goals four and five are part of the Data and 
Information Management syllabus. The 
simulation allows students to experience the 
system through participation and discussion with 
classmates, and thus more fully understand the 
system and its weaknesses, which is strongly 
aligned to what they would experience in 
industry. This insight creates a basis on which 
students can create richer system development 
artifacts, even though the source of information 
is less clear than traditional written exercises in 
textbooks. Further, students are forced to make 
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assumptions and attempt to verify their own 
assumptions by working with classmates. 

Performance on the above assignments/project 
is the best way to assess student learning as a 
result of the simulation. Table 3 lists the major 
assignments/project in the courses, the learning 
goal(s) that each assignment/project support, 
and the average grade assigned to deliverable. 


Assignment/Project 

Avg 

Score 

Learning Goal 

Supported 

Assignment l:Use Case 
Modelinq 

91% 

• Learning Goal 1 

Assignment 2: Structural 
Modeling (Class 

Diaqrams) 

87% 

• Learning Goal 2 

Assignment 3: 

Behavioral Modeling 
(Sequence Diagrams) 

94% 

• Learning Goal 2 

• Learning Goal 3 

Assignment 4: 

Behavioral Modeling 
(Sequence Diagrams & 
State Diagrams); 

Process Diagrams 
(Activity Diagrams) 

94% 

• Learning Goal 2 

• Learning Goal 3 

Assignment 5: Process 
Modeling (data flow 
diagrams to support 

their data model. 

85% 

• Learning Goal 3 

Database Course Project 

94% 

• Learning Goal 4 

• Learning Goal 5 


Table 3. Learning Goals Assessment 


The scores earned on the assignments ranged 
from 85% to 94%, which suggests that the 
students were successful in reaching the 
learning goals. Assessing the direct contribution 
of the simulation to student learning, however, 
is difficult as it is only one week in a semester. 
All students participated in the simulation and, 
thus, there was no control group to compare 
performance against. Furthermore, we cannot 
make a direct comparison between the grades 
given to students in the term the simulation was 
used and previous terms because the 
assignments following the simulation were much 
more difficult. In previous terms, the students 
were given a clear set of requirements and only 
needed to create the models. The instructors 
did not observe any noticeable differences in the 
technical quality of student models, though the 


expert judgment of the faculty was that the 
simulation did lead to greater learning as 
assignments became more complex and a wider 
range of skills were necessary to complete those 
more rigorous assignments. For example, the 
students were more restricted in the 
assumptions they could make because more 
facts were presented in the simulations package. 
In future semesters, additional metrics will be 
collected so that the direct impact of the 
simulation on learning can be quantified. 

5. CONCLUSIONS 

The simulation emerged out of our shared desire 
to create a problematic business context that 
the students, as a whole, could understand while 
experiencing some degree of vagueness and 
uncertainty. The simulation was prerequisite to 
creating an opportunity for students to more 
fully develop their requirements determination 
and modeling skills. 

Providing a chance for the students to become 
part of the system they were modeling, presents 
an additional, complementary approach to 
understanding requirements determination 
techniques. A simulation like Fetch encourages 
a greater degree of student involvement in the 
assignment leading to more active involvement. 

To the best of our knowledge, we know of no 
other program that has developed an IS 
simulation where (1) the students have a hands- 
on experience running a fictional business in 
order to "live" the requirements, (2) the 
experience is shared by two courses 
demonstrating the big picture of how the 
techniques learned in each class capture 
different, complementary aspects of systems 
definition, and (3) the experience is a focal point 
throughout the semester. 

6. REFERENCES 

Bandy, D. B. (2005). In-Class Simulation of 
Pooling Safety Stock. Decision Sciences 
Journal of Innovative Education, 3(2), 375- 
380. 

Byrd, T. A., Cossick, K. L., & Zmud, R. W. 
(1992). A synthesis of research on 
requirements analysis and knowledge 


©2015 EDSIG (Education Special Interest Group of the AITP) 
www.aitp-edsig.org /www.isedj.org 


Page 20 




Information Systems Education Journal (ISEDJ) 

ISSN: 1545-679X 

acquisition techniques. MIS Quarterly, 117- 
138. 

Dennis, A., Wixom, B.H., &Tegarden, D. (2012). 
Systems Analysis and Design with UML, 4th 
ed, Wiley. 

Derrick, J. & Haggerty, N. (2001). Systems: A 
Pedagogy for Developing Team Skills and 
High Performance. Environment, 1(1), 14. 

Cronan, T. P., & Douglas, D. E. (2012). A 
student ERP simulation game: A 

longitudinal study. Journal of Computer 
Information Systems, 53(1). 

Dalai, N. (2012). Teaching Tip: Using Rapid 
Game Prototyping for Exploring 
Requirements Discovery and Modeling. 
Journal of Information Systems Education, 
23(4), 341-344. 

Goodwin, J. S., & Franklin, S. G. (1994). The 
beer distribution game: using simulation to 
teach systems thinking. Journal of 
Management Development, 13(8), 7-15. 

Hanchey, D. (2002) Lessons Learned in Teaching 
a Software Projects Course. In The 
Proceedings of the Information Systems 
Education Conference, v 19 (San Antonio): 
§321b.ISSN: 1542-7382. 

Hoffer, George, and Valacich, (2014) Modern 
Systems Analysis and Design, 7th ed., 
Upper Saddle River, NJ. 

Hu, S., Kuh, G. D., & Li, S. (2008). The effects 
of engagement in inquiry-oriented activities 
on student learning and personal 
development. Innovative Higher Education, 
33(2), 71-81. 

Jeffries, P. R. (2005). A frame work for 
designing, implementing, and evaluating 
simulations used as teaching strategies in 
nursing. Nursing Education Perspectives, 
26(2), 96-103. 

Keys, A. C. (2003). Using group projects in MIS: 
strategies for instruction and management. 
Journal of Computer Information Systems, 
43(2), 42-50. 


13(4) 
July 2015 


Klassen, K., & Willoughby, K. (2003). In-class 
simulation games: Assessing student 
learning. Journal of Information Technology 
Education: Research, 2(1), 1-13. 

Kolb, D. (1983). Experiential learning: 
Experience as the source of learning and 
development. Englewood Cliffs, NJ; 
Prentice-Hall 

Kuh, G. D. (2008). Excerpt from "High-Impact 
Educational Practices: What They Are, Who 
Has Access to Them, and Why They 
Matter". Association of American Colleges 
and Universities. 

Leemkuil, H., de Jong, T., de Hoog, R., & 
Christoph, N. (2003). KM QUEST: A 
collaborative Internet-based simulation 
game. Simulation & gaming, 34(1), 89-111. 

Lunce, L. M. (2006). Simulations: Bringing the 
benefits of situated learning to the 
traditional classroom. Journal of Applied 
Educational Technology, 3(1), 37-45. 

McConnell, Steve (2004). Code Complete (2nd 
ed.). Microsoft Press, p. 29. 

Montgomery, K., Brown, S., & Deery, C. (1997). 
Simulations: Using experiential learning to 
add relevancy and meaning to introductory 
courses. Innovative Higher Education, 
21(3), 217-229. 

Neufeld, D. J., & Haggerty, N. (2001). 

Collaborative team learning in information 
systems: A pedagogy for developing team 
skills and high performance. Journal of 
Computer Information Systems, 42(1), 37- 
43. 

Queen, J. A. (1984). Simulations in the 
classroom. Improving College and 
University Teaching, 32(3), 144-145. 

Whitten, J.L. & Bentley, L.D., (2007) Systems 
Analysis and Design Methods, 7th ed., 
McGraw-Hill Irwin. 


©2015 EDSIG (Education Special Interest Group of the AITP) 
www.aitp-edsig.org /www.isedj.org 


Page 21 



Information Systems Education Journal (ISEDJ) 
ISSN: 1545-679X 


13(4) 
July 2015 


Appendix A. Description of Preparation for Simulation 


1) Form teams and assign roles to students. 

a) General Manager 

b) Operations Manager 

c) OE Clerk 

d) PO Clerk 

e) Shop Floor Employee 

f) Shipping Clerk 

g) Quality Control Specialist 

2) Prepare Rooms 

a) Move desks and chairs into plant configuration (see Figure 2) 

b) Post signs indicating department 

c) Setup bins and the appropriate number of raw goods and finished goods 

3) Distribute job descriptions and procedures to each department 

a) Exhibit A - Customer Order 

b) Exhibit B - Finished Goods Inventory on Hand 

c) Exhibit C - Shipment Log 

d) Exhibit D - Work Order 

e) Exhibit E - Finished Goods Shortage Memo 

f) Exhibit F - WO Quality Guidelines 

g) Exhibit H - Reorder Point Memo 

h) Exhibit I - Purchase Order Form 

i) Exhibit J - Raw Goods Inventory on Hand 

j) Exhibit K - Suppliers 

k) Exhibit L - Receipt Log 

l) Exhibit M - Contractual Price List 

m) Exhibit N - Product Price List 

n) Exhibit O - Customer Profile 

o) Exhibit P - Raw Goods Consumption Report 

p) Exhibit Q - Inventory Allocation Notice 

q) Exhibit R - Customer List 

r) Exhibit S - Finished Goods Replenishment Notice 

s) Bill of Materials 

4) Run 30 minute exercise 

5) Collect number of customer orders shipped 

6) Breakdown Room 


_ Appendix B. Purchase Order Clerk Procedures _ 

1. Retrieve updated Raw Goods Inventory on Hand from mailbox. 

2. Use Raw Goods Inventory on Hand and Reorder Point Memo to determine which items must 
be ordered. 

3. Create a Purchase Order for the appropriate supplier to order the needed raw goods. The 
supplier address is on the Suppliers list, and the prices are on the Contractual Price List. 
Repeat until all needed raw goods are ordered. Make two copies of each Purchase Order. 
Record the Purchase Order in the Purchase Order Ledger for each one created. 

4. Put one copy of the Purchase Order in the Outgoing Mailbox, and send one to the Shipping 
Dept. 

5. When Purchase Orders are returned from the Shipping Department and marked received, 

_ update the Purchase Order Ledger. _ 


©2015 EDSIG (Education Special Interest Group of the AITP) 
www.aitp-edsig.org /www.isedj.org 


Page 22 




Information Systems Education Journal (ISEDJ) 
ISSN: 1545-679X 


13(4) 
July 2015 


Appendix C. Survey Results 


Item 

Area of 
Interest 

Frequency 

Mean 

St. 

Dev. 

1 

2 

3 

4 

5 

6 

7 

As a learning experience, this 
simulation was more productive than 
listening to a lecture. 

Productive 

1 

1 

2 

7 

19 

35 

25 

5.74 

1.19 

As a learning experience, this 
simulation was more enjoyable than 
listening to a lecture. 

Enjoyment 

1 

0 

0 

3 

8 

27 

51 

6.36 

0.98 

Compared to group projects in other 
business-related courses, this 
simulation was more productive. 

Productive 
/ Teams 

1 

0 

2 

6 

19 

38 

24 

5.80 

1.09 

Compared to group projects in other 
business-related courses, this 
simulation was less enjoyable. 

Enjoyment 
/ Teams 

30 

39 

12 

5 

2 

1 

1 

2.08 

1.16 

As a result of completing this 
simulation, I have a greater 
appreciation for what it takes to work 
in a qroup. 

Teams 

2 

3 

1 

8 

18 

44 

14 

5.50 

1.29 

This simulation should not be used in 
future classes. 

General 

43 

32 

6 

7 

1 

0 

1 

1.83 

1.10 

This simulation was one of the best 
parts of the systems analysis and 
database courses so far. 

General 

1 

0 

2 

11 

13 

36 

27 

5.79 

1.18 


1= Strongly Disagree, 2 = Disagree, 3=Somewhat Disagree, 4=Neither Agree nor Disagree, 5=Somewhat 
Agree, 6=Agree, 7 = Strongly Agree _ 


Areas of interest: 


Productive 


They were asked about the relative learning productivity of the simulation 
and should it be used again. 


Enjoyment 


They were asked which was more enjoyable 
lectures. 


the simulation or traditional 


Teams 


They were asked 
work in teams. 


if they better understood the effort required 


to effectively 
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